Application No. 10/078,815 

Reply to Office Action of October 7, 2005 



REMARKS 

Claims 2-27 and 29-54 are pending in this application. Claims 7, 13, 34 and 40 were 
rewritten independent form and the dependency of the remaining claims was revised accordingly. 
Claims 1 and 28 were canceled. Withdrawal of the outstanding rejections is respectfully 
requested for at least the reasons set forth below. 

Request for Interview Prior to Formal Action on Amendment 

Applicants request an interview prior to formal action on this response. An "Applicant 
Initiated Interview Request Form" accompanies this response. Please contact Applicants' 
undersigned representative to schedule the interview. 

Rejection under 35 U.S.C. § 102(b) 

Claims 1-3, 5-14, 18, 23, 26-30, 32-41, 45, 50, 53 and 54 were rejected under 35 U.S.C. 
§ 102(e) as allegedly being anticipated by U.S. Patent No. 6,505,249 (Rehkopf). The remaining 
claims (claims 4, 15-17, 19-22, 24, 25, 31, 42-44, 46-49, 51 and 52) were rejected under 35 
U.S.C. § 103(a) as allegedly being unpatentable (i.e., obvious) over Rehkopf Applicants 
respectfully traverse these rejections as they pertain to the currently pending claims. 

1. Rehkopf 

Rehkopf discloses a method for benchmarking and optimizing end-to-end processing 
performance of a computer network system. The method operates as follows: 

a. System performance variables are selected. 

b. A baseline performance test is run using an initial set of values for the system 
performance variables to produce a benchmark system performance. 

c. The system performance variables are fixed at the initial set of values. 

d. A floating variable is selected from among the system performance variables. 

e. Subsequent tests are run with the floating variable set to different values, and system 
performance indicators that result from each subsequent test are recorded. The system 
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performance indicators are compared to the benchmark system performance. An optimal value 
of the floating variable is then recorded that optimizes the system performance indicators. 

f. Another floating variable is then selected from among remaining system performance 
variables that have not yet been selected to be the floating variable. 

g. Steps (e) and (f) are repeated until all of the system performance variables have been 
selected as the floating variable. 

h. Each of the system performance variables are then fixed to its optimal value. 

Rehkopf s method can be characterized as a "brute force" method in that each system 
performance variable is individually tested while keeping the other system performance variables 
constant. (The system performance variable being tested during each iteration is the "floating 
variable.") 

Rehkopfs method has at least the following disadvantages: 

a. The test process may take a long amount of time because each system performance 
variable must be individually tested throughout its entire potential range of values. If there are a 
large number of system performance variables, the test time may be extremely long. 

b. After each system performance variable is individually tested, its "optimal value" is 
determined only in view of the initial values of the other system performance variables (which 
remain fixed at their initial values during the testing). However, it is very common that certain 
system performance variables affect other system performance variables. Thus, each system 
performance variable may actually have a better (i.e., more optimal) value if one or more of the 
other system performance variables were set to a value other than their initial values . Rehkopf 's 
method has no process for determining the best set of system performance variables. 

c. No prior knowledge of previously determined optimal system performance variables is 
used in Rehkopf Such knowledge could potentially speed up the testing process by reducing or 
eliminating the number of system performance variables that would need to be tested, or by 
reducing the range of values to be tested for the current floating variable. 
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2. Patentability of independent claims 7 and 34 over Rehkopf 

Claims 7 and 34 recite that a different predefined group of network configuration 
settings is selected for each test performed. No such limitation is disclosed or suggested in 
Rehkopf 

Assuming, arguendo, that the claimed set of network configuration settings are 
equivalent to Rehkopfs selected system performance variables, Rehkopf s testing process lacks 
the concept of having different predefined groups of network configuration settings. In Rehkopf, 
each test involves selecting a different value for a floating variable while keeping all of the other 
system performance variables fixed to an initial value. Since the floating variable is constantly 
changing, there is inherently no predefined group of system performance variables. To the extent 
that the non-floating variables can be considered a group of system performance variables, they 
are always set to the same fixed initial value, and thus also inherently cannot be a different group 
of system performance variables. 

Fig. 4 of the present application shows one preferred embodiment of different predefined 
groups of network configuration settings. Each test uses a different predefined group. Any 
network configuration setting can be selected in each group so that different combinations of 
network configuration settings can be arranged. The network configuration settings are fixed in 
each group, and thus there is no concept of a "floating variable." That is, the claimed scheme 
does not keep one network configuration setting fixed, while varying the others. Instead, it 
predefines potentially good combinations of fixed network configuration settings (e.g., by using 
test results fi'om previous users) and then allows a client to test multiple groups of such fixed 
combinations to identify an optimal combination for the particular client machine. 

In the outstanding Office Action, the Examiner states that column 2, line 59 through 
column 3, line 11 of Rehkopf discloses different benchmarking tests that are equivalent to claims 
7 and 34. Applicants respectfully disagree with that statement. Column 2, line 59 through 
column 3, line 1 1 of Rehkopf reads as follows: 

First, a set of performance variables that impact system 
performance is identified. These performance variables, also referred to as 
system destabilizers, influence the performance of the software, hardware, 
and network processes. Examples of these variables include the number 
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of central processing units (CPUs), the number of concurrent users, and 
the network protocols. Once the destabilizers are identified, a software 
matrix is constructed to represent and track the performance variables. 
Next, the functional (but not optimized) system is performance-tested. This 
initial performance test establishes the baseline for the system, which is 
recorded in the software matrix. 

With a baseline established, the performance variables are pinned 
to constant values except for one variable, which is allowed to float 
through different values. While this one variable is floating, system 
performance is recorded in the software matrix, including metrics pertinent 
to the particular software application, such as processing speed, system 
access and congestion, and system response time. Readings for each 
value of the floating variable are recorded as the values change through 
successive thresholds. 



The first paragraph of Rehkopf excerpted above (column 2, line 60 through 
column 3, line 3) merely describes the process for identifying potential system 
performance variables and establishing a baseline. This process is equivalent to steps a. 
and b. of Rehkopf described in section 1 of the Remarks. The baseline is established by 
running one test wherein each system performance variable has only one value (i.e., the 
initial value). There are no floating variables used when establishing the baseline. See 
Fig. 3 which clearly shows this process. There is no disclosure or suggestion in Rehkopf 
that different predefined groups of system performance variables are selected when 
establishing the baseline. 

The second paragraph of Rehkopf excerpted above (column 3, lines 4-11) merely 
describes the process for testing different floating variables and is equivalent to steps c. 
through g. of Rehkopf described in section 1 of the Remarks. For the reasons previously 
discussed, these steps also do not disclose or suggest selecting different predefined 
groups of system performance variables . 

In sum, column 2, line 59 through column 3, line 1 1 of Rehkopf does not provide any 
disclosure or suggestion of the above-highlighted limitations of claims 7 or 34. 
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3. Patentability of independent claims 13 and 40 over Rehkopf 

Claims 13 and 40 recite that a remote server stores network configuration settings and 
aggregate test results associated with other client machines that previously established a network 
connection with the remote server, and that a user's client machine receives network 
configuration setting recommendations fi*om the remote server, based on the network 
configuration settings and the aggregate test results stored on the remote server. No such 
limitation is even remotely disclosed or suggested in Rehkopf. 

In the outstanding Office Action, the Examiner states that "col. 2, 3" of Rehkopf 
discloses the limitations of claims 1 3 and 40. It is unclear what portion of colunm 2 the 
Examiner is relying upon. However, nowhere in column 2 is there any discussion of using test 
results from other client machines for benchmarking or testing a client machine, or of sending 
recommendations for baseline values or system performance variables to the client machine, or 
of using aggregate test results of other client machines in establishing baseline values or system 
performance variables on another client machine. Applicant has also reviewed all other portions 
of Rehkopf and cannot identify any disclosure or suggestion of such limitations. 

4. Advantages of claimed invention over Rehkopf 

The schemes in claims 7, 13, 34 and 40 do not suffer from the highlighted disadvantages 
of the Rehkopf scheme for at least the following reasons: 

a. The claimed test process can be performed very quickly because it is not necessary to 
vary each network configuration setting throughout a given range to identify an optimal value. 
Even if there are a large number of network configuration settings to test, the test time is 
determined only by the number of groupings to be tested (which can be limited to a small 
number based on various algorithmic techniques), not by the number of network configuration 
settings or their potential range of settings. 

b. The claimed test process is not constrained by always keeping certain network 
configuration settings to an "initial value" as described in Rehkopf s scheme. Based on past test 
data, the individual network configuration settings in each predefined group can be selected to an 
optimal value taking into account some or all of the other network configuration settings in that 
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particular group. The claimed process is thus a better technique to identify the truly best set of 
network configuration settings for a particular client machine. 

c. As described above, the claimed process can use prior knowledge of previously 
determined optimal network configuration settings to identify potentially good groups of 
network configuration settings, thereby potentially speeding up the testing process and 
improving the likelihood of identifying the truly best set of network configuration settings for a 
particular client machine. 

5. Patentability of dependent claims 

The dependent claims are believed to be allowable because they depend upon respective 
allowable independent claims, and because they recite additional patentable steps. 



Insofar as the Examiner's rejections were fully addressed, the instant application is in 
condition for allowance. A Notice of Allowability of all examined claims, and all withdrawn 
claims depending from the examined claims, is therefore earnestly solicited. 



Conclusion 



Respectfiilly submitted, 



ADAM R. SCHRAN et al. 
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